A Software Defined Radio (SDR) is a radio whose function is defined not by its underlying hardware, but instead by its software, such that its output signal is determined by software. SDR systems are thus reconfigurable, within the limits of the actual underlying hardware capabilities, by loading new software as required by a user. FIG. 1 is a block diagram of an exemplary prior art SDR system 20. The exemplary SDR system 20 includes a means for receiving an analog or digital radio waveform at a transmission frequency (e.g., an antenna 28 and associated hardware) along with an SDR hardware component 26, an SDR software component 24, and an SDR client 22.
The SDR hardware component 26 includes a radio receiver and/or radio transmitter (which is shown for illustrative purposes only in FIG. 1 as a radio transceiver 34), as well as an analog-to-digital (A/D) converter (ADC) 30 for conversion of the radio waveform 48 (also referred to as analog baseband input) is required) to a digital baseband input signal 44 to the SDR software c component 24, and a digital to analog (D/A) converter (DAC) 32, for D/A conversion of the digital baseband output 46 from the SDR software component 24. The radio transceiver 34 is a component well understood by those of skill in the art and includes, for example, a radio frequency (RF) subsystem 38 and an intermediate frequency (IF) subsystem 36. In the receiving mode, signals received by the antenna 28 are processed by the RF subsystem 38 and IF subsystem 36: for example, the signals received at antenna 28 can be processed in a tuner (to select the desired signal, such as by filtering), a detector (to extract audio signal from the signal selected by the tuner), downconverted to the desired baseband frequency, and then sent to the ADC 30 to be converted from an analog baseband signal 48 to a digital baseband data signal 44.
In the transmit mode, the digital baseband output signal 46 from the SDR software component 24 is sent to DAC 32 for conversion to an analog baseband output signal 49, the analog baseband output signal 49 is sent the IF subsystem 36 and RF subsystem 38 of the radio transceiver 34 to the basic radio transceiver 26 for further processing, which may include upconverting the analog baseband output signal 49 to the appropriate transmission frequency, amplification, and filtering, then sent to antenna 28 for transmission.
The SDR software component 24 runs on a host, which can be a general-purpose computer system (such as described further herein in connection with FIG. 2), or hardware that has been configured by software, such as a field-programmable gate array (FPGA), embedded computing device, multiprocessor embedded systems, any equivalent computing/processing circuit. A waveform can consist of a set of SDR software components executing on general purpose processors, FPGA's, digital signal processors, etc. The host is able to handle a considerable amount of the signal processing previously done by conventional radio hardware components such as mixers, filters, amplifiers, modulators/demodulators, detectors, etc. Thus, the SDR system 20 provides a radio that can receive and transmit widely different radio protocols (sometimes referred to as waveforms) based solely on the software used.
The SDR software component 24 is in operable communication with the SDR hardware component 26 via one or more data channels. For example, in FIG. 1, the data channels include a first data channel 44 that permits reception of digital baseband input data from the ADC 30 of the SDR hardware component 26, a second data channel 46 that permits transmission of digital baseband output data from the SDR software component 24 to the SDR hardware component 26, and a control data channel 47 that permits transmission of control data from the SDR software component 24 to the SDR hardware component 26. The SDR software component 24 receives client input data 40 from an SDR client 22 and sends client output data 42 to the SDR client 22.
The digital baseband output 46 typically results from the SDR software component 24 performing a series of digital signal processing (DSP) functions necessary to prepare the client input data 40 from the SDR client 22 for transmission by the SDR hardware component 26. These functions may include: source encoding, encryption, error-correction coding, and baseband modulation, as well as the aforementioned functions performed by hardware components such as mixers, filters, amplifiers, modulators/demodulators, detectors, etc.
The SDR software component 24 of FIG. 1, as noted above, as well as the SDR client 22, each can be implemented using a known computing system such as a general purpose computer. FIG. 2 provides an illustration giving an overview of an exemplary computing system 50 usable with at least some embodiments of the invention. Note that systems and methods in accordance with the invention can be implemented using any type of computer system running any one or more types of operating systems. Exemplary types of computer systems on which at least some embodiments of the invention can be embodied include any system or device having a processor (or equivalent processing functionality) installed or embedded, including but not limited to a desktop computer, personal computer (PC), laptop computer, notebook computer, tablet computer, handheld computer, netbook, personal digital device (including but not limited to personal digital assistant (PDA), mobile communications device (including but not limited to radio, conventional telephone, mobile/cellular telephone, smart phone, music playing device, electronic reading device) server, workstation, and interconnected group of computers, as well as any other type of device having a microprocessor installed or embedded thereto, such as a field-programmable gate array (FPGA).
Referring now to FIG. 2, the computer system 50 includes a central processor 1, associated memory 2 for storing programs and/or data, an input/output controller 3, a disk controller 4, a network interface 5, a display device 7, one or more input devices 8, a fixed or hard disk drive unit 9, a removal storage device/drive (optional) 13, optionally a backup storage device (e.g., a tape drive unit) (not shown) and a data bus 6 coupling these components to allow communication therebetween.
The central processor 1 can be any type of microprocessor, such as a PENTIUM-family processor, made by Intel of Santa Clara, Calif. The display device 7 can be any type of display, such as a liquid crystal display (LCD), plasma display, cathode ray tube display (CRT), light emitting diode (LED), and the like, capable of displaying, in whole or in part, any desired information. The input device 8 can be any type of device capable of providing the desired inputs, such as keyboards, numeric keypads, touch screens, pointing devices, switches, styluses, and light pens. The network interface 5 can be any type of a device, card, adapter, or connector that provides the computer system 50 with network access to a computer or other device, such as a printer. For example, the network interface 5 can enables the computer system 50 to connect to a computer network such as the Internet. Other computer accessories well-known to those of skill in the art (e.g., microphones, cameras, speakers, biometric access-control devices such as fingerprint scanners, etc.), although not illustrated in the block diagram of FIG. 2, can of course be included as part of the computer system 50.
SDR is advantageous, flexible, efficient, and economical for users, because the SDR can evolve to meet changing or new standards by replacing software. In addition, use of SDR improves interoperability, because groups that each use SDR devices based on incompatible standards can communicate with each other by loading each group's SDR device with software that enables the two incompatible SDRs to communicate. SDR can be advantageous in military applications, and the United States Department of Defense (DoD), through its, Joint Tactical Radio System (JTRS) Joint Program Execute Office (JPEO) in San Diego, Calif., now requires that all radios delivered to any of the armed forces adhere to a so-called “Software Communications Architecture” (SCA) specification for SDR, which specification is hereby incorporated by reference in its entirety. Goals of the SCA standard include allowing all military branches to cooperate, reduce cost, increase interoperability, and provide the ability to upgrade and/or extend such SDRs developed in accordance with the SCA, from either or both of the software and hardware sides of the radio.
Several versions of the SCA specification have been developed. At the time of this writing the latest specification prepared by the STRS JPEO is SCA 2.2.2 dated 15 May 2006, the entirely of which is hereby incorporated by reference, including all of its appendices, including Appendix A (Glossary), Appendix B (Application Environment Profile (AEP)), Appendix C (Interface Definition Language (IDL)), Appendix D (Domain Profile), Appendix D (Common Properties) Attachment, Appendix D (Common Properties) Readme Attachment. In addition, as of this writing, a new proposed SCA specification, tentatively referred to as SCA NEXT, was introduced in December 2010. Both SCA 2.2.2 and SCA NEXT, including all Appendices, are hereby incorporated by reference.
FIG. 3A is an illustrative block diagram of a prior art SCA architecture 10 (developed in accordance with SCA 2.2), which architecture illustrates the general structure of its software architecture. FIG. 3B is a prior art block diagram 11 showing the core framework (CF) layer 16 interface definition language (IDL) relationships of the prior art architecture of FIG. 3A. The prior art systems of FIGS. 3A and 3B are described briefly below and in greater detail in the SCA 2.2.2 specification itself. The elements in and operation of FIGS. 3A and 3B, along with a detailed description of a related prior art embedded distributed XML parser, are further described in commonly-assigned U.S. Pat. No. 7,367,020 (“the '020 patent”), entitled “Executable Radio Software System and Method,” which is herein incorporated by reference in its entirety.
As illustrated in FIGS. 3A and 3B, software used in at least some SCA architectures/systems 10 is organized into three layers: a processor environment layer (including operating system 12), a middleware layer 14, and a so-called “core framework” (CF) layer 16 (also referred to as a component framework layer), which includes a CF layer IDL 16a and CF layer services and applications 16b. This layer structure helps to isolate the waveform applications from the radio hardware. The processor environment layer and the middleware layer are generally commercially available off-the-shelf products. The CF layer 16, however, which is defined to be an open means to promote plug-and-play software interoperability, has been developed by a number of different suppliers, including but not limited to Raytheon Corporation of Waltham, Mass., ITT Industries of Clifton N.J., BAE Systems of the United Kingdom; Boeing Corporation of Chicago, Ill.; PrismTech of Woburn, Mass.; Communications Resource Center (CRCO) of Ottawa, Ontario Canada, and Selex Communications of Italy, as well as universities such as the Virginia Polytechnic Institute An exemplary prior art CF layer 16 implementation is application independent, but also can be platform dependent.
The CF layer 16 also is the essential set of open application interfaces and services that provide an abstraction of the underlying Commercial Off-The-Shelf (COTS) software and hardware. Portability is achieved by implementing this same set of CF layer 16 application program interfaces on every platform. One purpose of the CF layer 16 is to deploy (load and execute) a distributed application in a controlled and secured manner. At startup, the CF layer 16 reads information in the Domain Profile (described further below) and attempts to deploy a given application to the platform, in accordance with relationships defined in the Domain Profile. Although the Domain Profile is not depicted in this figure, it is well understood by those skilled in the art and familiar with the SCA; further as those of skill in the art are aware, XML parsing of the domain profile inherently is one of the services that the CF layer 16 uses. The CF layer 16 is able to download a component (e.g., a software component) to a device, couple components together to enable them to communicate, stop and start components, handle errors, and perform other management tasks for the components. As illustrated in FIG. 3B, the CF layer 16 includes a CF Interface Definition Language (IDL) 16a and CF layer services and applications 16b. CF layer services 16b, in one exemplary prior art embodiment, consist of a Domain Manager that implements system control, a Device Manager that loads software and manages a set of hardware devices, and core services such as Log, File Manager, and File System. The CF layer 16 also includes a domain manager that managers the software applications, applications factories, hardware devices, and device manager. Although the details of the CF layer's domain manager and service 16b are not expressly illustrated in FIG. 3B, such services are known to those of skill in the art and, furthermore, are shown and described in further detail in the aforementioned SCA 2.2.2 Specification and '020 patent, which are incorporated by reference.
The aforementioned Domain Profile includes a set of files in eXtensible Mark-up Language (XML) format. As is known in the art, XML is a set of rules for encoding documents in machine readable form. An XML parser parses an XML-encoded document so as to convert the XML-encoded document into an XML Document Object Model (DOM), which can then be manipulated (e.g., displayed in a browser), where the XML parser ensures that the document meets defined structures, validation, and constraints (which can be defined in a document type definition (DTD)). For example, the SCA defines XML DTDs for application, device, and service deployment information, all of which are used by the SCA Domain Manager, Application Factory, and Device Manager components of the SCA. FIG. 6, described further herein, depicts the set of XML DTD types.
The Domain Profile is a hierarchical collection of XML files that define the properties of all software components in the system and describes the SCA system's components and connections between components and describes various aspects of the hardware and software devices making up the SCA system, including the identity, capabilities, properties (including properties of embedded hardware devices), and interdependencies, as well as information about the external interfaces of the components and devices, their implementations, and how they are connected to form applications and platforms. An exemplary Domain Profile includes a set of descriptor files for describing the application (the Software Profile) and a set of descriptor files for describing the platform (the Device Profile).
Often the Domain Profiles can include a large amount of information (e.g., tens of thousands of lines of XML code spread over hundreds of files). At runtime, the XML Domain Profile is read to get configuration and deployment information. The parsing of these XML Domain Profile files, and the interpretation of the parsed data by the SCA CF, loads software components of the SCA and creates the connections between such software components and thus enables the radio to operate. The XML Domain Profile can be parsed by the SCA CF layer 16 each time the SCA radio is turned on or when an application is installed into the radio Domain. The result, in some instances, is the requirement of multiple distributed software components within the radio Domain to parse XML files.
One way the prior art CF layer 16 deploys the distributed application is through the use of CORBA. CORBA is the acronym for Common Object Request Broker Architecture, which is a standard defined by the Object Management Group (OMG) that enables software components written in multiple computer languages and running on multiple computers to work together as a single application or set of services. CORBA uses an interface definition language (IDL) to specify interfaces that objects will present to the outside world, and specifies a mapping from the IDL to a specific implementation language. Because of the use of the CORBA distributive middleware layer and Portable Operating System Interface (POSIX)-compatible open system environment, the CF layer 16 supported components can port with relative ease across different processors, Real Time Operating Systems (RTOSs), buses and Object Request Brokers (ORBs). Further information about CORBA can be found in the CORBA Specification, version 3.1 (January 2008), including Part 1 (CORBA Interface) and Part 2 (Interoperability), available from the Object Management Group (OMG)), 109 Highland Ave, Needham, Mass. 02494. The CORBA Specification is hereby incorporated by reference in its entirety.
Referring again to FIGS. 3A and 3B the middleware layer 14 typically includes CORBA. (distributive middleware layer) and Real Time Operating System (RTOS). As noted above, the prior art system of FIGS. 3A and 3B, as implemented in the '020 patent, also includes an embedded distributed XML parser that parses Domain profiles (which typically are defined in the SCA) of the applications for more efficiently installing and running the application. The CF layer 16 Domain Management subsystem is advantageously configured to invoke the XML parser only upon the installation of a new application or device.